Labels:text | screenshot | font | number OCR: Myth 1. You must dolavet components for every cell. Truth 1. You should select only those cells ywinse deliverables will assist in achieving specific business gne's and intimegrating the enterprise. Every cell costs money to deliver and maneje Myth 2. As you define deliveranks downthe zad unan Truth 2. As you go down the Zachmen rows, the deliverables represent the same constaicts as in the firevious foly Cis you adid niche detail thus, row 2, called business bet from a different perspective You may Therefore add components to a row that represesits Reins of interest for model, is a conceptual model and eny 3, Called infor- that perspective, but you are not necessanly adding more detail to the constructs represented in other mows marjan systems modells a more detared mode Myth 3, The deliverables in each cell must be perfect" Truth 3. The deliverables in each tak most be useful but not necessarily perfect, In practice, I have delivered now 3 data models in which some entities were analyzed tonvan enterprise perspective and other ercities for a single apolice- ton's perspective Statuses that differentiate between foodel constructs representing an enterprisenide perspective and those represething an application perspective are invaluable. They indicate the conotrosts aoturacy, completeness, and expected flexibility If an enterprisewide construct fails to be reusable or shareable, the archict is at fault If an appli. cation-specific constrict falls to accommodate a future requirement, it & no orin's but, the consinxf was never expected to meet future requirements. Blorts should be made to modify sisch a construct rather than coate a new version: Ina cost of modification or recasting should be captured to document the most/benefits of architecture. Myth 4. The network columin is the technology Truth 4. The network column is the kkatoo column It prescribes where processes happencuitiere data is stored, columnin and where business n'es execute Technology implications apply to every colurin, Myth 5. You may find it useful to add or delete nws Truth 5. The Zachman Framework IS complete in its cepktion of the scope of architecture There are only sic in; Ik rollmir lo the Zachman Framework to meet your. termeatives in any language, corresponding to Who, What, Where, Why When, and How You may of course, elect noi requirements: to foginalze deliverables for some cell. These cells are not deleted som you architecture You simply make as sumptionis about them in the absence of formal deliverables. Myth 6. You mius: store deliverables from all cess in Truth 6. This practice is ir deed ideal Yet some organizations use the Zachmich framework as an index of the de one repository. werables stored in various tools inneed one cell may include a variety of deliverables, such as firma models word processing documents, and mnaces For a business audience, a more intuitive business-oriented GUL interfere inar hirovlile access to an underlying categorization of architecture deliverables based on the Zachraan framework. Myth 7. The Framework does not lend iself to Truth 7. The framework is compatible with object orientation. You must express the concept of an object in terimis of the interoratives it addresses and the perspective it serves M. for example, you consider an object to be the ec. capsulalico of data, process, and rules for the information systems audience, then à deliverable comprising such ob- jects fits into row 3, columns 1,2,and 6 TABLE 1 . Common myths about the use of the Zachman Framework for architecture.
(1999).iso/dbprd/nov96/von0t101.gif){kind=small}
(1999).iso/dbprd/nov96/tanrf104.gif){kind=link}
(1999).iso/dbprd/nov96/wintf101.gif){kind=link}